Currently available Java™-based enterprise servers can typically include several thousand technical components that generate hundreds of thousands (or even larger numbers) of data records. Each of the components and data records is capable of generating or storing data. Java™ (available from Oracle Corporation of Redwood City, Calif.) and other platform-independent programming languages (referred to throughout this disclosure with the generic term “platform-independent programming language”) generally do not require manual management of every bit of application memory. A process referred to as garbage collection generally includes functionality that removes from system memory objects that are no longer needed. Effective garbage collection in a platform-independent programming language aids memory management by eliminating unwanted data, also called garbage. However, currently available garbage collection programs do not address all memory problems. For example, memory leaks in a platform-independent programming language can be difficult to find, detect, and eliminate. In other words, it is not always clear, particularly during runtime, which objects are no longer needed. Memory leaks can result from design and implementation errors (for example, a reference to an object being retained beyond the useful life of the object). Thus, currently available garbage collection approaches can only detect and eliminate typical heap management problems, but are little help in finding memory leaks. Memory leaks can be harmful, because eventually they can lead to a crash of the virtual machine within which platform-independent programming language code executes.
Existing tools, such as allocation traces and heap dumps, do not generally allow identification of the statements where those objects are allocated that contribute to the memory leak. Determining which combination of object creation and data structure manipulation causes a leak is a task that can require a thorough understanding of the code. Unfortunately, memory leaks are often detected long after the code was written, which can lead to challenges in understanding what parts of the code are the likely sources of a problematic object reference. Even with well-understood code, however, the task of identifying a memory leak can be tedious, and can require significant effort and potentially collaboration among several people (e.g. the developer, a software testing team, end users experiencing the memory leaks, etc.). For at least these reasons, memory leaks often take several months to rectify.
Co-pending and co-owned U.S. Patent Application Publication No. 2011/0029822A1 describes approaches to identifying statements in a program coded using a platform-independent programming language that allocate objects in a manner that could contribute to a memory leak. An allocation trace and a heap dump are created, and the heap dump is used to identify which data structures are leaking. The allocation trace records where objects are allocated. The information on the leaking data structures extracted from the heap dump is combined with the allocation information produced by the allocation trace. An algorithm can identify objects that are part of the leaking data structure and locations in the platform-independent programming language where the identified objects are allocated in the code.